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Abstract 

The standard procedure for hardware design consists of describing circuit in a hardware description 
language at logic level followed by extensive verification and logic-synthesis. However, this process 
consumes significant time and needs a lot of effort. An alternative is to use formal specification language 
as a high-level hardware description language and synthesize hardware from formal specification. In [T] 
formal specifications for AMBA AHB Arbiter were presented and synthesized. Our contributions are as 
follows: (1) We present more complete and compact formal specifications for the AMBA AHB Arbiter, 
and obtain significant (order of magnitude) improvement in synthesis results (both with respect to time 
and the number of gates of the synthesize circuit); (2) we present formal specification and synthesize to 
generate compact circuits for the remaining two components of the AMBA AHB protocol, namely, the 
AMBA AHB Master and AMBA AHB Slave; and (3) from the lessons learnt we present few principles for 
writing formal specifications for efficient hardware synthesis. Thus with systematically written complete 
formal specifications we are able to automatically synthesize an important and widely used industrial 
protocol. 

1 Introduction 

Hardware design flow. The first step in traditional standard industrial procedure of hardware design is 
the decription of a circuit in hardware description language. This step is followed by extensive verification 
and subsequently by logical synthesis. The outcome of logical syntehsis is gate level implementation of 
circuit. Among the above steps of design, verification and logical synthesis, the verification step is most time 
consuming process and requires a lot of effort. An alternative approach is to automatically synthesize the 
circuit from formal specification. 

Synthesis from formal specification. Historically, automatic synthesis of digital designs from logical 
temporal specifications has been considered as one of the most challenging problems in circuit design. The 
problem was first presented by Church [J and several methods have been proposed as solutions such as [3] 
and in jl2j . The problem was considered again in |10| in the context of synthesizing reactive modules from a 
specification given in Linear Temporal Logic (LTL). The method proposed in [lOj for a given LTL specification 
Lp starts by constructing a Biichi automaton which is converted into a deterministic Rabin automaton. This 
translation may require a doubly exponential complexity in the size of Lp. The high complexity established 
in |10| caused synthesis to be deemed hopelessly intractable and discouraged practitioners from attempting 
to use it for system development. Yet, there exist several interesting cases where, if the specification of the 
design to be synthesized is restricted to simpler automata or partial fragments of LTL, it has been shown 
that the synthesis problem can be solved in polynomial time. Major progress has been achieved in [5], which 
shows that designs can be automatically synthesized from LTL formulas belonging to the class of generalized 
reactivity of rank 1 (GR(1)), in time where N is the size of the state space of the design. The class 
GR(1) covers the vast majority of properties that appear in specifications of circuits. The approach of [3] 
was implemented by [T] in a tool called Anzu [B]. Anzu produces not only a BDD representing a set of 
possible implementations, but also an actual circuit. 

AMBA AHB Protocol. In this work we study the automatic synthesis of an important and widely 
used industrial protocol, namely, AMBA AHB protocol. ARM's Advanced Microcontroller Bus Architecture 
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(AMBA) [5] specification defines an on cliip communications standard for designing high-performance em- 
bedded microcontrollers. AMBA is today the de-facto standard for embedded processors because it is well 
documented and can be used without royalties. It is widely used in network interconnect chips, RAM and 
Flash memory controllers, DMA controllers, level2 cache controllers and SoCs including application proces- 
sors used in portable mobile devices like smartphones, and a few industrial examples of its use are IXP42X 
Product Line of Intel Network Processors, Infineon gateway controller ADM5120. The most important bus 
defined within the AMBA specification is Advanced High-performance Bus AHB. The AHB acts as the high- 
performance system backbone bus. AHB supports the efficient connection of processors, on-chip memories, 
DMA controllers and off-chip external memory interfaces. The AMBA AHB design consists of the following 
main components: (a) AHB Arbiter; (b) AHB Master and (c) AHB Slave. In this work we synthesize the 
above three components of the AMBA AHB protocol. 

Our contributions. The contributions of this work are as follows: 

1. In [T] and [5] the synthesis of only AMBA AHB Arbiter was studied. We present more complete and 
compact formal specifications for the AMBA AHB Arbiter, and obtain significant (order of magnitude) 
improvement in synthesis results (both with respect to time and the number of gates of the synthesized 
circuit). 

2. We present, for the first time, the formal specifications for the AMBA AHB Master and AMBA AHB 
Slave (the remaining two components of the protocol). We are able to synthesize very compact circuits 
from our formal specifications. Thus we are able to completely synthesize an important and widely 
used industrial protocol by systematically writing the formal specifications. 

3. From the lessons that we have learnt in the process of rewriting specifications to obtain efficient syn- 
thesis result, we present few principles for writing formal specifications for efficient hardware synthesis. 

2 Preliminaries 

In this section we present preliminaries related to specification language and synthesis. 

2.1 Property Specification Language 

We will use Property Specification Language (PSL) to express specifications (a detailed description of PSL 
can be found in [5]). The specifications presented in this paper are easy to follow for readers familiar with 
LTL. In particular, always, eventually, and next correspond to G, F , and X, respectively. The untiL operator 
requires the first operand to hold either forever or up to and including the time that the second operand 
holds. The construct ($ before ^P) is equivalent to (-i^* untiL $). We also use one operator that is not in 
PSL: ($ untiL[i] ^E") means that $ holds either forever or up to and including the i^^ time that \I/ holds. 

2.2 Synthesis of GR(1) Properties 

We briefly review the results presented in [S] on synthesizing GR(1) properties. We are interested in the 
question of realizability of PSL specifications (cf [11]). Assume two sets of Boolean variables X and Y . 
Intuitively X is the set of input variables controlled by the environment and Y is the set of system variables. 
Realizability amounts to checking whether there exists an open controller that satisfies the specification. 
Such a controller can be represented as an automaton which, at any step, reads values of the X variables 
and outputs values for the Y variables. 

Here we concentrate on a subset of PSL for which realizability and synthesis can be solved efficiently. 
The specifications we consider are of the form (j) = (f)'^ ^ We require that (jf for a e {e,s} can be 
rewritten as a conjunction of the following parts. 

• (/)"- a Boolean formula which characterizes the initial states of the implementation. 
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• - a formula of the form Ai (always Bi) where each Bi is a Boolean combination of variables from 
X UY and expressions of the form (next v) where v € X if a — e, and v £ X UY otherwise. 

• 4>g - has the form Ai^j (always eventually Bi) where each Bi is a Boolean formula. 

In order to allow formulas of other forms (e.g. always(p — >■ (q untiL r)) where p, q, and r are Boolean), we 
augment the set of variables by adding deterministic monitors. Deterministic monitors are variables whose 
behavior is deterministic according to the choice of the inputs and the outputs. These monitors follow the 
truth value of the expression nested inside the always operator. We rewrite these types of formulas to the 
form (always eventually b) where 6 is a Boolean formula using the variables of the monitor. It should be noted 
that even with these restrictions, all possible (finite state) designs can be expressed as a set of properties. 

We reduce the realizability problem of a PSL formula to the decision of the winner in a two-player game 
played between system and environment. The goal of the system is to satisfy the specification regardless of 
the actions of the environment. A game structure is a multigraph whose nodes are all the truth assignments 
to X and Y . A node vi is connected by edges to all the nodes V2 such that the truth assignments to X 
and Y satisfy (j^l f\ (j)l , where vi supplies the assignments to the current values and V2 to the next values. 
We then group all the edges that agree on the assignment of X in V2 to one multi-edge. A play starts by 
the environment choosing an assignment to X and the system choosing a state in A (/)f that agrees with 
this assignment. A play proceeds by the environment choosing a multi-edge and the system choosing one of 
the nodes connected to this multi-edge. The system wins if this interaction produces an infinite play that 
satisfies i/i^ <^g- 

We solve the game to decide whether the game is winning for the environment or the system. If the 
environment wins, then the specification is unrealizable. If the system wins, then we synthesize a winning 
strategy. This strategy, a BDD, is a nondeterministic representation of a working implementation. The 
following theorem summarizes the result of synthesis of PSL specifications. 

Theorem 1 J§j Given sets of variables X and Y and a PSL formula (j) of the form presented above with m 
and n conjuncts, we can determine using a symbolic algorithm whether (j) is realizable in time proportional 
to 0{mn2'^^^'^^^^^^) , where d is the number of variables added by the monitors for <p. 

2.3 Generating circuits from BDDs 

We briefly review the results presented in [2] on generating circuits from BDDs. The strategy is a BDD 
over the variables X, y, X and Y , where X are input variables, Y are output variables and the primed 
versions represent next state variables. The corresponding circuit contains \X\ + \Y\ fiipflops to store the 
values of the inputs and outputs in the last clock tick. In every step, the circuit reads the next input values 
X and determines the next output values using combinational logic with inputs / = XUYUX and outputs 
O ^ Y . The strategy does not prescribe a unique combinational output for every combinational input. In 
most cases, multiple outputs are possible, in states that are not reachable (assuming that the system adheres 
to the strategy), no outputs may be allowed. 

We write o 6 O for a combinational output and i £ / for a combinational input. The strategy is denoted 
by S and O \ o is the set of combinational outputs excluding output o. For every combinational output o we 
construct a function / in terms of / that is compatible with the given strategy BDD. The algorithm proceeds 
through the combinational outputs o one by one: First, we build S to get a BDD that restricts only o in 
terms of /. Then we build the positive and negative cofactors {p, n) of S with respect to o, that is, we find 
the sets of inputs for which o can be 1 (0, respectively). For the inputs that occur in the positive and in the 
negative cofactor, both values are allowed. The combinational inputs that are neither in the positive nor in 
the negative cofactor are outside of the winning region and thus represent situations that cannot occur (as 
long as the environment satisfies the assumptions). Thus, / has to be 1 in p A -in and in -ip A n, which 
give us the set of care states. We minimize the positive cofactors with the care set to obtain the function /. 
Finally, we substitute variable o in 5* by /, and proceed with the next variable. The substitution is necessary 
since a combinational outputs may be related. 
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The resulting circuit is constructed by writing the BDDs for the functions using CUDDs DumpBhf 
command [13]. We then optimize the result using ABC [14] and map it to a library of standard cells. We 
also use ABC to estimate the number of gates needed. 

3 AMBA AHB Protocol 

In this section we describe the details of the main components of the AMBA AHB protocol. ARM's Advanced 
Microcontroller Bus Architecture (AMBA) [8j specification defines an on chip communications standard for 
designing high-performance embedded microcontrollers. The most important bus defined within the AMBA 
specification is Advanced High-performance Bus. The AHB acts as the high-performance system backbone 
bus. AHB supports the efficient connection of processors, on-chip memories, DMA controllers and ofF-chip 
external memory interfaces. The AMBA AHB design contains the following components: 

AHB master: A bus master is able to initiate read and write operations by providing an address and 
control information. Only one bus master is allowed to actively use the bus at any one time. 

AHB slave: A bus slave responds to a read or write operation within a given address-space range. The bus 
slave signals back to the active master the success, failure or waiting of the data transfer. 

AHB arbiter: The bus arbiter ensures that only one bus master at a time is allowed to initiate data 
transfers. Even though the arbitration protocol is fixed, any arbitration algorithm, such as highest priority 
or fair access can be implemented depending on the application requirements. 

AHB decoder: The AHB decoder is used to decode the address of each transfer and provide a select signal 
for the slave that is involved in the transfer. 

Consider an AHB system with arbiter, masters and slaves. Every slave shall have some address range. 
AHB decoder receives address as input, checks in which range that address lies and provides select signal 
for slave that corresponds to this address. In essence, it works as a de-multiplexer. For a system with single 
slave, the select signal shall always be high, if valid address is put on bus. Hence we consider the synthesis 
of the main components of AHB design i.e. AHB Master, AHB Slave and AHB Arbiter. 

3.1 AHB Arbiter 

The role of the arbiter in an AMBA system is to control which master has access to the bus. Every bus 
master has a REQUEST/ GRANT interface to the arbiter and the arbiter uses a prioritization scheme to 
decide which bus master is currently the highest priority master requesting the bus. Each master also 
generates an HLOCKx signal which is used to indicate that the master requires exclusive access to the bus. 
The arbitration protocol is not specified and can be defined for each application. 

3.2 AHB Master 

Function of AHB master is to do read and write operations. Before initiating any transfer, it sends a request 
to arbiter for accessing bus. Once arbiter grants the bus, master initiates read/write operation by providing 
address and control information. Master is the default master and is selected whenever there are no 
requests for the bus. 

3.3 AHB Slave 

An AHB bus slave responds to transfers initiated by bus masters within the system. The slave uses a select 
signal HSELx from the decoder to determine when it should respond to a bus transfer. All other signals 
required for the transfer, such as the address and control information, will be generated by the bus master. 

The AHB is a pipelined bus. This means that different masters can be in different stages of commu- 
nication. At one instant, multiple masters can request the bus, while another master transfers address 
information, and a yet another master transfers data. A bus access can be a single transfer or a burst, which 
consists of a specified or unspecified number of transfers. Access to the bus is controlled by the arbiter. All 



4 



devices that are connected to the bus are Moore machines, that is, the reaction of a device to an action at 
time t can only be seen by the other devices at time t + 1. 



4 AMBA AHB Arbiter Synthesis 

In this section we present our resuhs related to synthesis of AHB arbiter. We first present the arbiter signals, 
then present the formal specifications and our result for synthesis. 



4.1 AHB Arbiter Signals 
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Figure 1: AHB Arbiter [8] 

Figure [T] shows AHB arbiter signals. The description of these signals are as follows (the notation S[n:0] 
denotes an (n+l)-bit signal): 

• HBUSREQi - A signal from bus master i to the bus arbiter which indicates that the bus master requires 
access to the bus. 

• HLOCKi - Indicates that the master requires locked access to the bus. No other master should be 
granted the bus until this signal is lowered. 

• HREADY- This signal is driven by the bus slave. It indicates that a transfer has finished on the bus. 
This signal may be lowered to extend a transfer. 

• HGRANTi - This signal indicates that if HREADY is high, then HMASTER= i will hold in the next 
tick. 

• HMASTLOCK - Indicates that the current master is performing a locked sequence of transfers. 

• HMASTER[3:0] - These signals from the arbiter indicate which bus master is currently performing a 
transfer. 

The following signals are multiplexed using HMASTER as the control signal. For example, although every 
master has an address bus, only the address provided by the currently active master is visible on HADDR. 

• HADDR [3 1:0] - These signals indicate the address where read or write transaction will take place. 
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• HBURST[1:0] - One of SINGLE (a single transfer), INCR (unspecified length burst) or INCR4 (burst 
of four transfers). Though the standard allows for burst of eight and sixteen transfers too but we have 
not taken them into account. That would lengthen the specification. 

• HTRANS[1:0] - Indicates the type of the current transfer, which can be NONSEQ, SEQ or IDLE. The 
standard allows for BUSY transfers also. HTRANS = BUSY indicates that master wants to introduce 
some delay during ongoing transfer. This is an optional feature. For simplicity we have left this feature 
out. 

Furthermore, as an optional feature of the AHB, a slave is allowed to split a burst access and request that 
it be continued later (signals HRESP and HSPLIT shown in Figure [T] serve that purpose) . We have left this 
feature out for simplicity. 

Both optional features i.e. SPLIT and BUSY transfers are also not considered in [T] while writing 
specifications for AHB Arbiter. Though they can be handled by this approach but that would lengthen the 
specification. 

4.2 Formal Specifications 

The first formal specification for AMB A AHB arbiter was given in [1] . We have systematically re- written the 
specifications to make it more complete. The two important changes are as follows: (a) the HTRANS [1:0] 
signal, which plays an important role in AHB transfers, was not used in earlier specifications, whereas with 
the use of HTRANS signal, we make the formal specifications more complete; and (b) the other important 
change from the specifications of [T] is related to de-assertion of HLOCK signal: according to ARM [7], the 
AHB Master should dcasscrt the HLOCK signal when the address phase of the last transfer in the locked 
sequence has started. 

Along with the signals described above, we use two auxilary signals DECIDE and BUSREQ, that were 
introduced in [2]. The signal DECIDE indicates the time slot in which the arbiter decides who the next 
master will be and whether its access will be locked. The decision is based on HBUSREQi and HLOCKi. The 
signal BUSREQ points to the HBUSREQi signal of the master that currently owns the bus. Two auxilary 
variables START and LOCKED, that were introduced in [T], are not used in our specification. It is because 
with the inclusion of HTRANS signal and change of nature in de-assertion of HLOCK signal, START and 
LOCKED have become redundant. We introduce a new auxilary variable GRANTED which is driven by 
the arbiter. The signal GRANTED is used for deciding start of new access. When both GRANTED and 
HREADY signals are high simultaneously, new access shall start in next cycle. Thus a decision can be 
executed at the earliest two time steps after the HBUSREQi and HLOCKi signals are read. 

We follow the convention used in [1]: guarantees are properties that the arbiter must fulfill, and assump- 
tions are properties that the arbiters environment must fulfill. Our specification for the arbiter consists of 9 
assumtions and 12 guarantees whereas the specification from paper [1] had 4 assumptions and 11 guarantees. 
Figure 2 shows timing diagram for AHB arbiter signals. Table 1 contains formal specification of arbiter in 
PSL. The bold faced A and G signify new/re- written property whereas non-bold faced indicate existing 
property from [2]. The assumptions(A) and guarantees(G) for the arbiter are described below. 

Assumptions The assumptions are as follows. 

Al During a locked unspecified length burst, leaving HBUSREQi high locks the bus. This is forbidden by 
the standard. 

A2 Leaving HREADY low locks the bus, the standard forbids it. 

A3 Signals HLOCKi and HBUSREQi are asserted by AHB Master at the same time. 

A4 When HREADY signal is low, all control signals should hold their values. 

A5 If no transfer is taking place, HTRANS signal can not become SEQ in the next cycle. 

A6 In burst sequence (i.e. HBURST = INCR4), if HREADY is high, NONSEQ transfer shall always be 

followed by SEQ transfer. 
A7 First transfer of any AHB sequence is NONSEQ in nature. 

A8 When none of the AHB Masters is making a request for bus, no transfer will take place. 
A9 All input signals arc low initially. 
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Figure 2: Signals for the AHB Arbiter and timing diagram 
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Table 1: PSL Specifications for AHB Arbiter. 



Al 


Mi : always ((HMASTLOCK A HBURST = INCR) ^ ( next eventually ^BUSREQ)) 


A2 


always eventually HREADY 


A3 


Vi : always ((^HBUSREQ; A ^HLOCKi A (next HLOCK;)) ^ (next HBUSREQ;)) 


A4 


always (^HREADY ^ (HTRANS = j ^ next HTRANS = j)) 
always i ^nxxi-j-riu i — r injj uxxox — j v-? nexi nijujnoj- — jii 


A5 


always ((HTRANS = IDLE) ^ (next (HTRANS / SEQ))) 


A6 


always (((HTRANS = NONSEQ) A (HBURST = INCR4) A HREADY) ^ (next (HTRANS = SEQ))) 


A7 


always ((GRANTED A HREADY) ^ (next (HTRANS = NONSEQ))) 


A8 


always ((Ar=})^HBUSREQi) ^ (HTRANS = IDLE)) 


A9 


Vi : (^HBUSREQi A^HLOCK; A^HREADY A (HTRANS = IDLE) A (HBURST = SINGLE)) 


Gl 


Vi : always ((HMASTER = i ) ^ (BUSREQ o HBUSREQ;)) 


G2 


Vi : always ((HMASTLOCK A (HBURST = INCR) A HREADY A (HTRANS = NONSEQ)) ^ 
next ((HTRANS = SEQ) until. ^BUSREQ)) 


G3 


Vi : always ((HMASTLOCK A (HBURST = INCR4) A HREADY A (HTRANS = NONSEQ)) ^ 
next ((HTRANS = SEQ) until_[3] HREADY)) 


G4 


always ((DECIDE A(Vf=o HBUSREQ;)) (next GRANTED)) 


G5 


always ((GRANTED A^HREADY) ^ (next GRANTED)) 
always ((GRANTED A HREADY) ^ (next ^GRANTED)) 


G6 


Vi : always (HREADY ^ (HGRANTi ^ next (HMASTER = i))) 


G7 


always ((HREADY A(Vf=o (HLOCK; A HGRANT;)) ^ next (HMASTLOCK))) 


G8 


Vi : always ((^HREADYV ^GRANTED) ^ (HMASTER= next HMASTER^ i)) 
Vi : always ((^HREADYV ^GRANTED) ^ (HMASTLOCK^ next HMASTLOCK)) 


G9 


Vi : always (^DECIDE ^ (HGRANT; o next HGRANT;)) 


GIO 


Vi / : always (^HGRANT; ^ (HBUSREQ; before HGRANT;)) 
always (DECIDE AVi : ^HBUSREQ; -> next HGRANTO) 


GU 


Vi : always (HBUSREQ; ^ eventually (^HBUSREQ; V (HMASTER = i))) 


G12 


DECIDE A HGRANTO A (HMASTER = 0) A ^GRANTED A^HMASTLOCK AVi / : ^HGRANT; 



Guarantees Tlie guarantees are as follows. 

Gl Variable BUSREQ points to HBUSREQ; of the master that is currently granted access to the bus. 
G2 When a locked unspecified length burst starts, a new access does not start until the currentmaster (i) 

releases the bus by lowering HBUSREQi. 
G3 When a length-four locked burst starts, no other accesses start until the end of the burst. We can only 

transfer data when HREADY is high, so the current burst ends at the fourth occurrence of HREADY. 
G4 Whenever, there is at least one bus request present and signal DECIDE is high, GRANTED gets asserted 

in the next cycle. 

G5 If HREADY is low, then GRANTED signal holds its value. Whereas, if HREADY and GRANTED 

signals are simultaneously high, then GRANTED gets deasserted in next cycle. 
G6 The HMASTER signal follows the grants: When HREADY is high, HMASTER is set to the master that 

is currently granted. It implies that no two grants may be high simultaneously and the arbiter cannot 

change HMASTER without giving a grant. 
G7 Whenever signal HREADY, HLOCK; and HGRANT; are simuhaneously high, HMASTLOCK gets 

asserted in the following cycle. 
G8 When any of GRANTED or HREADY signals is low, the HMASTER and HMASTLOCK signals do 

not change. 



8 



G9 Whenever DECIDE is low, HGRANT; signal do not change. 

GIO We do not grant the bus without a request, except to Master 0. If there are no requests, the bus is 
granted to Master 0. 

Gil We have a fair bus i.e. every master that has made a request shall be serviced eventually. 
G12 The signals DECIDE and HGRANTO are high at first clock tick and aU others are low. 

Assumptions Al, A2, A3, A9 and Guarantees Gl, G2, G3, G6, G8, G9, GIO, Gil, G12 mentioned above 
are taken directly from [1] . Remaining guarantees in [1] were related to auxilary signals which have become 
redundant in our case with inclusion of HTRANS signal. Out of the above, G2, G3 and G8 have been 
re-written with the original meaning kept intact. Thus all assumptions and guarantees from [T] are taken 
care in our specification, and along with it we have more assumptions and guarantees. 

4.3 Synthesis Results 
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Table 2: Synthesis time comparison 



Anzu [B] is used to synthesize the circuit from specifications. Table [2] shows comparison of time taken 
by Anzu tool to synthesize AHB arbiter for different specifications. First column shows number of masters 
for which arbiter was synthesized. Second column shows data taken from Figure 8 of [2] and third column 
shows time taken in synthesizing specification from [5] on our machine (2GB RAM). In fourth column, we 
have taken the minimum of these two columns to have the best possible estimate of synthesis time for arbiter 
specifications in [5]. Fifth column shows the time in seconds for the arbiter synthesized using our formal 
specifications. 

The results (Table [2]) show that using the earlier specifications from [2] , the synthesis procedure fails for 
more than 10 masters. With our improved specifications we can synthesize arbiter serving upto 16 masters 
nearly in an hour. The AHB standard allows for maximum 16 masters, and arbiter synthesized using 
our specifications can serve upto 16 masters. Thus we are able to syntesize arbiter serving the maximum 
number of masters as required by the protocol. Moreover, our improved specifications show significant (order 
of magnitude) improvement over the earlier specification: for example, for arbiter serving 10 masters the 
synthesis of earlier specifications takes nearly 5 hours, whereas our specification is synthesized in less than 
11 minutes. 

In Table m NA corresponds to not available and NM refers to not mappable by ABC. 



9 



Num of 


Gate count from 


Gate count for 


Minimum gate 


Gate count for 


Masters 


Fig 9 in [2] 


specifications [2 in 


count of the last 


our specifications 






our experiments 


two columns 




2 


1000 


982 


982 


182 


3 


3500 


2626 


2626 


409 


4 


8500 


6801 


6801 


776 


5 


11000 


9033 


9033 


920 


6 


18000 


12448 


12448 


1443 


7 


15000 


19777 


15000 


2015 


8 


36000 


NM 


36000 


2431 


9 


NA 


50012 


50012 


3047 


10 


50000 


45912 


45912 


2825 


11 








2994 


12 








5178 


13 








3712 


14 








4112 


15 








4199 


16 








6056 



Table 3: Gate count comparison 



Anzu [B] tool generates a file in .blif format. This file is mapped by using ABC [13] to standard library. 
ABC tool is also useful for counting number of gates required to realize the circuit. Table|3]shows comparison 
of number of gates mapped by ABC for realizing different specifications for arbiter. First column shows the 
number of masters for which the arbiter is synthesized. Second column shows data taken from Figure 8 in [2] 
and third column shows number of gates mapped by ABC tool on our machine (2GB RAM) for existing 
specification in [2] . In fourth column, we have taken the minimum of second and third columns to have a best 
estimate of number of gates for existing specifications. In fifth column, gate count for our circuit synthesized 
from our specification. Table[3]shows that arbiter synthesized using specifications from [2] serving 10 masters 
has nearly forty-six thousand gates, whereas, the AHB arbiter synthesized with our specifications serving 10 
masters has only three thousand gates, and even arbiter serving 16 masters needs only six thousand gates. 
Thus our specifications not only improve the time taken for synthesizing, but also improve the gate count of 
synthesized circuit by an order of magnitude. 

Graphical comparison for arbiters serving different number of masters is shown in Figure [3] and Figure |4l 
Figure |3] shows comparison for synthesis time whereas Figure |4] depicts comparison for gate count. 

5 AMBA AHB Master 

In this section we present the synthesis results for AHB Master: we first present the signals, then the 
specification, and then the synthesis results. 

5.1 AHB Master Signals 

We first introduce the signals for AHB Master that have not been introduced. 

• HWRITE - This signal from bus master indicates nature of transfer. When HWRITE is low, it indicates 
read transfer. If high, it indicates write transfer. 

• HADDR[31:0] - These signals from the master provide information about location where write or read 
transfer shall take place. 

• HWDATA[31:0] - These signals from the master provide information about data to be written in case 
of write transaction. 
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Number of Masters 



Figure 3: Synthesis Time Comparison. Figure 4: Gate Comparison. 

• HRDATA[31:0] - These signals from bus slave to bus master provide information about data read in 
case of read transaction. 

• HSIZE[2:0] - This signal from bus master to bus slave provides information about bus width. It can 
be one of byte(8-bit), half-word(16-bit), word(32-bit) and up to 1024 bits. We have fixed it to word 
i.e. data bus shall be 32-bit wide. 

• HRESP[1:0] - This signal from bus slave to bus master provides transfer response. It can be one of 
OKAY, ERROR, SPLIT and RETRY. SPLIT and RETRY are optional feature allowed in standard. 
For simplicity, we have fixed it to OKAY otherwise it would lengthen the specification. 

The AMBA AHB specification also allows protection controls but for simplicity, we have left that feature 
. Few auxilary signals are also used. They are as follows: 

• REQ_VLD - This signal is input to bus master. It is used by bus master for deciding HBUSREQ. 
HBUSREQ signal is asserted whenever REQ_VLD is asserted. 

• WR - This signal is input to bus master. It indicates that write transaction shall take place. HWRITE 
shaU be HIGH if WR is high. 

• RD - This signal is input to bus master. If high, it indicates that read transaction shall take place and 
hence HWRITE shall be set LOW. 

• LENl - This signal is input to bus master. It indicates that single transfer shall take place. 

• LEN4 - This signal is input to bus master. It informs that the transfer should be a burst sequence of 
four transfers. 

• LENX - This signal is input to bus master. It informs that the transfer should be a burst sequence of 
unspecified length. 

• IN_ADDR[31:0] - These signals are input to the master providing information about address. These 
signals arc used to decide HADDR. 

• IN_DATA[31:0] - These signals are input to the master providing information about write data. These 
signals are used to decide H WD ATA. 

• LAST - This signal is input to bus master. It indicates the last transfer in a sequence of transfers. 

• OUT_DATA[31:0] - These signals from the master provide information about read data. 

• REQ_ADDR - This signal from the master is request for address. If this signal is high, in the next 
clock cycle, master shall receive IN_ADDR. 

• REQ_WR_DATA - This signal from the master is request for data. If this signal is high, in the next 
clock cycle, master shall receive IN_DATA. 
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Figure 5: AHB Master 



• REC_RD_DATA - This signal from the master provides acts as vahd signal for read data. If it is high, 
HRDATA shall be copied to OUT.DATA. 

Figure [5] shows signals for AHB Master and Figure |6] shows timing diagram for those signals. 
5.2 Formal Specifications 

In the formal specification of AMBA AHB Master, we have 10 assumptions and 15 guarantees. 
Assumptions The assumptions are as follows. 

Al Length of transfer will be specified with REQ_VLD signal i.e. whenever REQ_VLD is high, one of LENl, 

LEN4 and LENX signal shall be high. 
A2 Nature of transfer will be specified with REQ_VLD signal i.e. whenever REQ_VLD signal is high, one 

of RD and WR signal shall be high. 
A3 If REQ.VLDsignal is low, RD, WR, LENl, LEN4 and LENX shah hold their values. 
A4 There can not be conflict between signals indicating nature of transfer thus RD and WR signal can not 

be high simultaneously. 

A5 There can not be conflict between signals indicating length of transfer thus LENl, LEN4 and LENX 

signals can not be high simultaneously. 
A6 Input HRESP signal shah be OKAY throughout. 

A7 The bus is fair one, hence every HBUSREQ shall eventually be answered. 

A8 During a locked unspecified length burst, leaving HBUSREQ high locks the bus. This is forbidden by 

the standard. 
A9 Eventually HREADY will be high. 

AlO We are not considering it as default bus master for the sake of generality. Hence eventually REQ_VLD 
and HGRANT signals will be low. 
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Figure 6: Signals for the AHB Master 



We are assuming that data bus is 32-bit wide, hence HSIZE will be fixed to WORD. To make this bus 
master more general, another assumption is that this bus master requests for only locked transfers. 

Guarantees The guarantees are as follows. 

Gl Data bus is 32-bit wide. Thus HSIZE shaU be fixed to WORD throughout. 
G2 HBUSREQ signal gets asserted and de-asserted with REQ_VLD. 
G3 Bus master requests only for locked transfer. 

G4 If the ongoing transfer is last transfer of an ahb sequence, HLOCK shall be lowered. 
G5 Length four burst (HBURST = INCR4) shall end at fourth occurence of HREADY. 
G6 HBURST shall be set according to length of the transfer indicated by LENl, LEN4 and LENX. 
G7 First transfer of an AHB sequence is always NONSEQ in nature. All following transfers in sequence 
shall be SEQ in nature. 
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G8 Nature of transfer shall be set according to WR and RD signals. 
G9 If HREADY is low, all control signals shall hold their values. 

GIO When HREADY and HGRANT arc simuhancously high, REQ_ADDR signal shall be high. It ensures 

that in next cycle, master can put address on address bus. 
Gil When both REQ_ADDR and WR signals are high, REQ_WR_DATA signal shall also be high. It 

ensures that data shall be put on data bus one cycle after address is put on address bus. 
G12 When a read transfer is taking place and HREADY is high, REC_RD_DATA signal shall also be high. 
G13 When REQ_ADDR is high, in the next cycle, incoming IN_ADDR shall be copied to address bus. 
G14 When REQ_WR_DATA is high, in the next cycle, incoming IN_DATA shall be copied to data bus. 
G15 When read transaction is in progress and HREADY is high, OUT _D ATA shall copy the value of 

HRDATA. 



5.3 Synthesis Results 

The synthesis time for the AHB Master is 8.3 seconds. The generated circuit is mapped using ABC tool. 
It has 157 gates with area 210 square units. It is a very small circuit even with respect to manual imple- 
mentations. Thus we are not only able to synthesize the AHB Master from its formal specifications, but the 
synthesized circuit is also very compact. 

6 AMBA AHB Slave 

In this section we present the synthesis results for AHB Slave. 
6.1 AHB Slave Signals 
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Figure 7: AHBSlave 

The signals that are useful for AHB slave are already described in previous sections. We have introduced 
an interface between slave and a memory so that read and write transactions can be implemented. We are 
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Table 4: PSL Specifications for AHB Master 



Al always (REQ.VLD ^ (LENX V LENl V LEN4)) 



A2 always 



REQ.VLD ^ (WR V RD)) 



always 
aiways 
A3 aiways 
always 
always 



(next ^REQ.VLD) 
(next ^REQ.VLD) 
(next ^REQ.VLD) 
(next ^REQ.VLD) 
(next ^REQ.VLD) 



(^LENl o (next ^LENl))) 
(^LENX ^ (next ^LENX))) 
(^LEN4 o (next ^LEN4))) 
(^WR ^ (next ^WR))) 
(^RD o (next -^RD))) 



always 
always 



WR 
RD - 



n RD) 
WR) 



always 
A5 always 
always 



LENX (^LENl V ^LEN4)) 
LENl ^ (^LENX V ^LEN4)) 
LEN4 (^LENX V ^LENl)) 



A6 always 



HRESP = OKAY) 



always 



REQ.VLD eventually HGRANT) 



A8 always 



(HLOCK A (HBURST = INCR)) ^ next eventually ^REQ.VLD) 



A9 always 



eventually HREADY) 



AlO always 



eventually (^REQ.VLD A ^HGRANT)) 



Gl always 



HSIZE = WORD) 



G2 always 



REQ.VLD ^ HBUSREQ) 



always 



(^HBUSREQ A next HBUSREQ A ^HLOCK) ^ next HLOCK) 



G4 always (LAST ^HLOCK) 

always ((HLOCK A (HBURST = INCR4) A HREADY A (HTRANS = NONSEQ)) 
next ((HTRANS = SEQ) until_[3] HREADY)) 



always 
G6 always 
always 



HBUSREQ A HGRANT A (HTRANS = IDLE) A HREADY A LENl ^ next (HBURST = SINGLE)) 
HBUSREQ A HGRANT A (HTRANS = IDLE) A HREADY A LENX ^ next (HBURST = INCR)) 
HBUSREQ A HGRANT A (HTRANS = IDLE) A HREADY A LENl ^ next (HBURST = INCR4)) 



always 
G7 always 
always 



HBUSREQ A HGRANT A (HTRANS = IDLE) A HREADY ^ next (HTRANS = NONSEQ)) 

^LAST A (HTRANS = NONSEQ) A HREADY next (HTRANS = SEQ)) 

(HTRANS = IDLE) ^ (HBURST = SINGLE)) 



always 
always 



HGRANT A (HTRANS = NONSEQ) A HREADY A WR HWRITE) 
HGRANT A (HTRANS = NONSEQ) A HREADY A RD ^ ^HWRITE) 



always 
always 



nHREADY ^ ((HTRANS = j) ^ next (HTRANS = j))) 
nHREADY ^ ((HBURST = j) o next (HBURST = j))) 



GIO always 



(HREADY A HGRANT) ^ REQ_ADDR) 



Gil always 



(REQ_ADDR A HWRITE) REQ_WR.DATA) 



G12 always ((HREADY A ((HTRANS = NONSEQ) V (HTRANS = SEQ)) A^HWRITE) ^ REC-R.D-DATA) 



G13 V^ : always (REQ_ADDR ^ ((next (IN_ADDRi = j)) ^ (next (HADDRi = j)))) 

G14 V^ : always (REQ_WR-DATA ^ ((next (INJATA; = j)) ^ (next (H WD ATA; = j)))) 

G15 Vi : always (HREADY A^HWRITE A ((HTRANS = SEQ) 

V (HTRANS = NONSEQ)) ^ ((next (HRDATA; = j)) o (next (OUTJDATA; = j)))) 
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considering memory with two status signals EMPTY and FULL. 

Two auxilary signals have also been added named START and LAST. START signal indicates start of 
an AHB transfer or sequence whereas LAST signal is used to indicate last transfer of an AHB sequence. 

The signals used in this interface are shown in Figure [T] Figure [S] shows the timing diagram from AHB 
slave signals. The description of signals used in interface between slave and memory is given below: 
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Figure 8: Signals for the AHB Slave 



• FULL - This signal is input to bus slave indicating memory is full. No more data can be written into 
it without first being read. 

• EMPTY - This signal is input to bus slave indicating memory is empty. No more data can be read 
from it without first being written. 

• ADDR[31:0] - These signals are output from slave providing address information. 

• DI[31:0] - These signals are output from slave and input to memory providing information about data 
that should be written into memory. 

• DO[31:0] - These signals are output from memory and input to slave providing information about data 
that has been read from memory. 

• RD - This signal is input to memory from slave. It indicates that the read operation is being executed. 

• WR - This signal is input to memory from slave. It indicates that the write operation is being executed. 

6.2 Formal Specifications 

In the formal specification of AMBA AHB Slave, we have 7 assumptions and 9 guarantees. They are as 
follows. 

Assumptions The assumptions are as follows. 

Al When the slave is not selected by the decoder, all control signals shall be low. 
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Table 5: PSL Specifications for AHB Slave 



Al always 


(^HSEL ((HTRANS = IDLE) A (HBURST = SINGLE) A ^HWRITE A ^START A ^LAST)) 




A2 always 


((HTRANS = IDLE) ^ ((HBURST = SINGLE) A ^HWRITE A ^START A ^LAST)) 




A3 always 


(START ^ (HTRANS = NONSEQ)) 




A4 always 


(^LAST A (HTRANS = NONSEQ) A HREADY ^ next (HTRANS = SEQ)) 




A5 always 

until 


((HLOCK A (HBURST = INCR4) A HREADY A (HTRANS = NONSEQ)) ^ next((HTRANS = 


SEQ) 


A cilurQirt.' 

rvu aiwayb 






always 
always 
A7 always 
always 
always 


(^HREADY ^((HBURST = j) ^ next (HBURST = j))) 
(^HREADY ^((HADDR = j) o next (HADDR = j))) 
(^HREADY ->((HWDATA = j) o next (HWDATA = j))) 
(^HREADY ^((DO = j) o next (DO = j))) 




Gl always 


(^HSEL ^ HREADY) 




G2 always 


(^HSEL ^ (HRESP = OKAY)) 




G3 always 


((HTRANS = IDLE) ^ (HRESP = OKAY)) 




„ , always 
G4 

always 


((WR A HSEL) ^ ^RD) 
((RD A HSEL) ^WR) 




Qg always 
always 


((HSEL A FULL A WR) ^ (HRESP = ERROR)) 
((HSEL A EMPTY A RD) ^ (HRESP = ERROR)) 




always 
Go , 

always 


((HSEL A ((HTRANS = NONSEQ) V (HTRANS = SEQ)) A HWRITE) ^ WR) 
((HSEL A ((HTRANS = NONSEQ) V (HTRANS = SEQ)) A^HWRITE) RD) 




G7 always 


((HSEL A ((HTRANS = NONSEQ) V (HTRANS = SEQ)) ^ ((HADDR = j) ^ (ADDR = j))) 




G8 always 


((HSEL A ((HTRANS = NONSEQ) V (HTRANS = SEQ)) A HWRITE) ^ ((HWDATA = j) ^ (DI 


= j))) 


G9 always 


;(HSEL A ((HTRANS = NONSEQ) V (HTRANS = SEQ)) A^HWRITE) ^ ((DO = j) o (HRDATA 





A2 When HTRANS is IDLE, all control signals sliall be low. 

A3 First transfer of any sequence is NONSEQ in nature. 

A4 Non-first transfer of an AHB sequence will always be SEQ in nature. 

A5 Burst sequence of length four shall end at fourth occurence of HREADY. 

A6 If this is last transaction of a sequence and next cycle is not start of another sequence, HTRANS shall 

be IDLE in next cycle. 
A7 If HREADY is low, all control signals, address and data buses shall hold their values. 

Guarantees The guarantees are as follows. 

Gl When the slave is not selected by the decoder, HREADY signal shall be high. 
G2 When the slave is not selected by the decoder, HRESP shaU be OKAY. 
G3 When no AHB transaction is taking place, HRESP shaU be OKAY. 
G4 RD and WR signal can not be high simultaneously. 

G5 If memory is full and write tranfcr is attempted, slave shall send ERROR response. Similarly, if memory 

is empty and read transfer is attempted, slave shall send ERROR response. 
G6 When slave is involved in a transfer, HWRITE is used to decide values of WR and RD. 
G7 When slave is involved in any transfer, signal HADDR is used to decide ADDR. 
G8 When slave is involved in write transfer, signal HWDATA is used to decide DI. 
G9 When slave is involved in read transfer, signal DO is used to decide HRDATA. 
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6.3 Synthesis Results 



The synthesis tnne for the AHB Slave is 21.5 seconds. The circuit generated, when mapped using ABC, has 
214 gates with area 429 unit squared. It is a very smaU circuit even with respect to manual implementations. 
Thus wc are not only able to synthesize the AHB Slave from its formal specifications, but the synthesized 
circuit is also very compact. 

7 Lessons Learned 

In the process of systematically re-writing the formal specifications for efficient synthesis, we learnt a few 
lessons about writing formal specifications for synthesis. We present these lessons with examples below. 

• In the process of writing specifications, wc should first simplify the design (if possible), write realizable 
specification for that can be synthesized efficiently for the simple design, and finally add necessary 
complexities to have the complete specification. For example, while writing AHB Master specifications, 
we first fixed all data and address signals width to one bit, synthesized the simpler design successfully 
and efficiently. This was followed by increasing data and address signal widths to 32-bit and adding 
necessary changes to AHB Master specifications to make it complete and synthesizable. 

• While writing specifications, proceeding with the execution order of events is helpful. For example, 
while writing AHB Arbiter specifications, we proceeded with writing properties related to requesting 
access, granting access followed by properties related to AHB transfers. 

• The use of auxilary signals is helpful in scenarios that cannot be emulated using only input output 
signals. For example, in AHB Slave specifications, we have introduced auxilary signals to emulate 
slave-memory interactions. 

• The eventual specifications were the most time-consuming and difficult ones for synthesis and they 
need special attention. 

In general, most data intensive applications are not reacive designs of degree one, and the above approach 
may not be ideal for those applications, but we believe that the above synthesis approach should work well 
for many control specific applications. 

Acknowledgment. We thank Barbara Jobstmann for explaining the changes made in the specifications 
from [5 to H]. 
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